Apparatus and method for generating on-screen-display messages using true color mode

ABSTRACT

An apparatus and concomitant method for generating an OSD message by constructing an OSD bitstream defining a plurality of &#34;true color&#34; pixels. The OSD bitstream contains an OSD header and OSD data. An OSD unit retrieves pixel control information from the OSD header which is programmed by a processor of a decoding/displaying system. The OSD header contains information that is used to program a color palette of the OSD unit and to provide instructions as to the treatment of the OSD data. If the &#34;True Color Mode&#34; is enabled in the OSD header, then the OSD unit will bypass the palette and treat the OSD data as true color pixels. Since the same chrominance components are shared between a pair of successive pixels, each successive set of four OSD data bytes represents the actual chrominance and luminance levels for two OSD pixels.

FIELD OF THE INVENTION

The present invention relates to a method and apparatus for generatingOn-Screen-Display (OSD) messages using a "true color mode". Moreparticularly, this invention relates to a method and apparatus thatincreases the number of available colors by treating the OSD data astrue color pixels instead of pointers to the entries of an OSD palette.

BACKGROUND OF THE INVENTION

On-Screen-Display messages play an important role in consumerelectronics products by providing users with interactive informationsuch as menus to guide them through the usage and configuration of theproduct. Other important features of OSD include the ability to provideClosed Captioning and the display of channel logos.

However, the changing standard of digital video technology presents anever increasing problem of generating and displaying OSD messages. Forexample, there are specific High Definition Television (HDTV)requirements that an HDTV must display up to 216 characters in four (4)"windows" versus the current National Television Systems Committee(NTSC) requirements of a maximum of 128 characters in one "window".These new requirements place severe strains on the decoding/displayingsystem used to decode and display television signals (e.g., HDTV, NTSC,MPEG, and the like), which must decode the incoming encoded data streamsand present the decoded data to a display system with minimal delays.Since OSD messages must be displayed (overlaid) with the video data, themicroprocessor of the decoding/displaying system must assign a portionof the memory bandwidth to perform OSD functions, thereby increasing thememory bandwidth requirements of a decoding/displaying system and theoverall computational overhead.

Thus, an OSD unit of a decoding/displaying system may incorporate alimited size palette to minimize hardware requirements and memoryaccess. Namely, the OSD unit employs a palette using a plurality ofregisters (entries), where each entry contains a representation ofchrominance and luminance levels for an OSD pixel. By encoding theaddresses (indices) to the palette as OSD data, a decoding/displayingsystem is able to minimize memory access and hardware requirements.

However, such systems are limited in the number of colors that areavailable for the display of an OSD message. Since the palette has afixed size, it is not well suited to changing standards that may requiresupport for an increased number of colors at a later time. For example,to increase the number of colors from 16 to 256 (standard VGA), wouldrequire that 240 additional registers be added to a palette thatcurrently supports only 16 entries.

Increasing the number of registers to the palette is certainly possible,but it is not cost effective and may introduce timing problems(especially for high palette access rate) and other integrated circuit(IC) design problems (e.g., increasing the area on an IC). Furthermore,updating an existing decoding/displaying system with a fixed sizepalette is difficult and expensive.

Thus, a need exists for a method and apparatus for increasing the numberof available colors for OSD messages without increasing the hardwarerequirements, e.g., the size of an OSD palette, of a decoding/displayingsystem.

SUMMARY OF THE INVENTION

The invention concerns an apparatus and concomitant method forgenerating OSD messages by constructing a valid OSD bitstream having aplurality "true color" pixels.

More specifically, in accordance with the invention, an OSD unitretrieves an OSD bitstream from a storage device. The OSD bitstreamcontains an OSD header and OSD data. The OSD header contains controlinformation that is used to program a color palette of the OSD unit andto provide instructions as to the treatment of the OSD data. The controlinformation is programmed by a processor of a decoding/displayingsystem. If the "True Color Mode" is enabled in the OSD header, then theOSD unit bypasses the palette and treats the OSD data as true colorpixels. Namely, each successive set of three OSD data bytes representsthe actual chrominance and luminance levels for an OSD pixel.

To further reduce memory bandwidth requirements, the same chrominancecomponents are repeated for the next pixel. Thus, effectively, each OSDpixel is represented by only 16 bits of data.

These and other aspects of the invention will be described with respectto the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

In the Drawings:

FIG. 1 is a block diagram of a decoding/displaying system including anOSD unit in accordance with an aspect of the invention;

FIG. 2 is a block diagram which discloses the structure of a sample OSDpixel bitstream using true color mode; and

FIG. 3 is a flowchart illustrating the method for constructing a validOSD bitstream with true color mode.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a block diagram of a decoding/displaying system fortelevision signals 100 (hereinafter decoding system). The decodingsystem comprises a processor 130, a random access memory (RAM) 140, aread-only memory (ROM) 142, an OSD unit 150, a video decoder 160, and amixer 170. The output of the mixer 170 is coupled to a display device190 via path 180.

The present invention is described below in accordance with the MPEGstandards, ISO/IEC international Standards 11172 (1991) (generallyreferred to as MPEG-1 format) and 13818 (1995) (generally referred to asMPEG-2 format). However, those skilled in the art will realize that thepresent invention can be applied or adapted to other decoding systemsimplementing other encoding/decoding formats.

In the preferred embodiment, the decoding system 100 performs real timeaudio and video decompression of various data streams (bitstreams) 120.The bitstreams 120 may comprise audio and video elementary streams thatare encoded in compliance with the MPEG-1 and MPEG-2 standards. Theencoded bitstreams 120 are generated by an encoder (not shown) and aretransmitted to the decoding system through a communication channel. Theencoded bitstreams contain a coded representation of a plurality ofimages and may include the audio information associated with thoseimages, e.g., a multimedia data stream. The multimedia source may be aHDTV station, a video disk, a cable television station and the like. Inturn, the decoding system 100 decodes the encoded bitstreams to producea plurality of decoded images for presentation on the display 190 insynchronization with the associated audio information. However, for thepurpose of this invention, the audio decoding function of the decodingsystem 100 is irrelevant and, therefore, not discussed.

More specifically, processor 130 receives bitstreams 120 and bitstreams110 as inputs. Bitstreams 110 may comprise various control signals orother data streams that are not included in the bitstreams 120. Forexample, a channel decoder or transport unit (not shown) can be deployedbetween the transmission channel and the decoding system 100 to effectthe parsing and routing of data packets into data streams or controlstreams.

In the preferred embodiment, processor 130 performs various controlfunctions, including but not limited to, providing control data to thevideo decoder 160 and OSD unit 150, managing access to the memory andcontrolling the display of the decoded images. Although the presentinvention describes a single processor, those skilled in the art willrealize that the processor 130 may comprise various dedicated devices tomanage specific functions, e.g., a memory controller, a microprocessorinterface unit and the like.

Processor 130 receives bitstreams 120 and writes the data packets intothe memory 140 via video decoder 160. The bitstreams may optionally passthrough a First-In-First-Out (FIFO) buffer (not shown) before beingtransferred via a memory data bus to the memory. Furthermore, there isgenerally another memory (not shown) which is used solely by theprocessor 130.

The memory 140 is used to store a plurality of data including compresseddata, decoded images and the OSD bit map. As such, the memory isgenerally mapped into various buffers, e.g., a bit buffer for storingcompressed data, an OSD buffer for storing the OSD bit map, variousframe buffers for storing frames of images and a display buffer forstoring decoded images.

In accordance with the MPEG standards, the video decoder 160 decodes thecompressed data in the memory 140 to reconstruct the encoded images inthe memory. In some cases, the decoded image is a difference signal thatis added to a stored reference image to produce the actual image inaccordance with the compression technique used to encode the image(e.g., to facilitate decoding a motion compensated image). Once an imageis reconstructed, it is stored in the display buffer pending display viathe mixer 170.

Similarly, the OSD unit 150 uses the memory 140 to store the OSD bit mapor the OSD specification. The OSD unit allows a user (manufacturer) todefine a bit map for each field which can be superimposed on the decodedimage. The OSD bit map may contain information which is stored in astorage device, e.g., a ROM, concerning the configuration and options ofa particular consumer electronics product. Alternatively, the OSD bitmap may contain information relating to Closed Captioning and channellogos that are transmitted from a cable television, a video disk and thelike. An OSD bit map is defined as a set of regions (generally inrectangular shapes) of programmable position and size, each of which hasa unique palette of available colors.

The OSD bit map is written into the OSD buffer of the memory 140 whichis assigned for this purpose by the user. However, those skilled in theart will realize that a ROM 142 or other equivalent storage devices canalso serve this function as well.

When the OSD function is enabled for a particular image or frame, theprocessor 130 manipulates the data in memory 140 to construct an OSDbitstream. The OSD bitstream contains an OSD header and OSD data (datadefining the OSD pixels).

More specifically, the processor 130 programs (formats and stores) theOSD header in the memory 140. The OSD header contains informationconcerning the locations of the top and bottom OSD field bit maps,palette data, pointer to the next header block and various display modesinvolving OSD resolution, color and compression. Once the OSD header isprogrammed, the processor 130 may manipulate the OSD data in the memory140 in accordance with a particular implementation. For example, the OSDdata is formatted in accordance with a selected mode, e.g., the TrueColor Mode as discussed below. Alternatively, the processor may simplyprogram the OSD header with pointers to the OSD data in the memory,where the stored OSD data is retrieved without modification to form theOSD bitstream.

The processor 130 then reports the enable status, e.g., OSD active, tothe OSD unit 150, which responds by requesting the processor 130 foraccess to the OSD bitstream stored within the memory 140. The OSDbitstream is formed and retrieved as the OSD unit reads the OSD headers,each followed by its associated OSD data. After receiving the OSDbitstream, the OSD unit processes the OSD pixel data in accordance withthe instructions or selected modes in the OSD header. The OSD unit thenwaits for a pair of display counters (not shown) to attain count valuesthat identifies the correct position on the display for inserting theOSD information. At the correct position, the OSD unit forwards itsoutput to the mixer 170. The output of the OSD unit 150 is a stream orsequence of digital words representing respective luminance andchrominance components of the on screen display. New memory accesses arerequested as required to maintain the necessary data flow (OSDbitstream) through the OSD unit to produce a comprehensive OSD display.When the last byte of the OSD pixel data for the current OSD region isread from the memory, the next OSD header is read and the process isrepeated up through and including the last OSD region for the currentframe.

Those skilled in the art will realize that the order of constructing andretrieving the OSD bitstream as discussed above can be modified. Forexample, the OSD header can be read from the memory as the processor isformatting the OSD data, or the OSD data can be processed and displayedas OSD messages by the OSD unit without having to retrieve the entireOSD bitstream.

Since OSD pixel data is superimposed on the decoded image, the mixer 170serves to selectively blend or multiplex the decoded image with the OSDpixel data. Namely, the mixer 170 has the capability to display at eachpixel location, an OSD pixel, a pixel of the decoded image or acombination (blended) of both types of pixels. This capability permitsthe display of Closed Captioning (OSD pixel data only) or the display oftransparent channel logos (a combination of both OSD pixels and decodedimage pixels) on a decoded image.

Video decoder 160 and OSD unit 150 both form streams or sequences ofdigital words representing respective luminance and chrominancecomponents. These sequences of video component representative digitalwords are coupled via mixer 170 to a digital-to-analog converter (DAC)185. The luminance and chrominance representative digital words areconverted to analog luminance and chrominance signals by the respectivesections of the DAC.

The OSD unit 150 can be used to display a user defined bit map over anypart of the displayable screen, independent of the size and location ofthe active video area. This bit map can be defined independently foreach field and specified as a collection of OSD regions. A region isoften a rectangular area specified by its boundary and by a bit mapdefining its contents. Each region has associated with it a palettedefining a plurality of colors (e.g., 4 or 16 colors) which can be usedwithin that region. If required, one of these colors can be transparent,allowing the background to show through as discussed above.

Although the use of a palette provides a substantial saving incomputational overhead for low resolution OSD implementations, it failsto provide the necessary display resolution as required for highresolution OSD implementations. For example, the OSD message may needmore colors than that are available in the palette, where the availablecolors are limited to the number of entries (or physical registers) inthe palette.

FIG. 2 illustrates the structure of a sample OSD bitstream 200 using thetrue color mode. The OSD bitstream comprises a plurality of OSD headers210, each followed by OSD data 220. In one embodiment, the header iscomprised of five 64-bit words, followed by any number of 64-bit OSDdata (bit map) words. The OSD header 210 contains information relatingto the OSD region coordinates 214, the various entries of the palette216 for a particular OSD region, and various function codes (bits) 212.Those skilled in the art will realize that the OSD header can be of anylength. A longer header can provide more information and options, e.g.,a palette with more entries, but at the expense of incurring a highercomputational overhead, i.e., more read and write cycles are required toimplement the OSD functions. In fact, the content of the OSD header isillustrative of a particular embodiment and is not limited to thespecific arrangement as illustrated in FIG. 2.

The OSD region coordinates 214 contain the positions of the left andright edge of an OSD region, i.e., row start and stop positions andcolumn start and stop positions. For interlaced display, the regioncoordinates include the positions (pointers) of the top and bottom fieldpixel bit maps for the corresponding OSD region. Finally, the OSD regioncoordinates 214 include a pointer to the next header block in thememory.

The palette information 216 contains a plurality of entries where eachentry contains a representation of chrominance and luminance levels foran OSD pixel. The palette information 216 is used to program the OSDpalette. Since each OSD header contains palette information 216, theavailable colors can be selectively changed for each OSD header and itsassociated OSD data bytes. Each palette entry may contain 16 bits ofdata, i.e., six (6) bits of luminance, Y, four (4) bits of chrominance(color difference signal), C_(b) and four (4) bits of chrominance (colordifference signal), C_(r). The remaining two bits are used to implementvarious display options that are irrelevant to the present invention. Inone embodiment, there are 16 entries in the palette requiring 4 bits toaddress each entry.

The function codes (bits) 212 contain information relating to variousmodes, including but not limited to, display options and OSD bitstreamoptions. In the preferred embodiment, the function bits contain a singlebit to indicate whether the "True Color Mode" is enabled.

The OSD data 220 contains bit map data in left to right and top tobottom order. The OSD data is generally used to define the color indexof each pixel in the bit map imagery. In the preferred embodiment, if"True Color Mode" is enabled, then the OSD data 220 contains true colorpixels (true color format) instead of indices to the palette. In thetrue color format, the OSD data stream consists of a byte of luminancecomponent (Y) 222, followed by two bytes of chrominance components(color difference signals, C_(b) 224 and C_(r) 226), followed by anotherbyte of luminance 228. This pattern is repeated for succeeding pixels asshown in FIG. 2. The length of each byte is generally set at 8 bits,thereby supporting millions of possible color combinations.

For this mode of operation, the OSD unit 150 simply bypasses the OSDpalette and passes the true color pixels directly to the mixer 170 asdiscussed above. Additionally, in order to support "transparent pixels"(where the decoded image from the video decoder is shown rather than theOSD pixels within an OSD region), the Y component is set to all "zeros".This setting causes the mixer 170 to replace the OSD pixel with acorresponding pixel from the decoded image.

Furthermore, the True Color Mode allows a reduction in memory bandwidthrequirements by repeating the same chrominance components for the nextpixel in the bit map. Namely, a pair of successive pixels share the samechrominance components.

To illustrate, FIG. 2 shows a plurality of data bytes (pixel data)defining pixels, 231-234, where each pixel data structure is 24 bitslong (eight bits of Y, eight bits of C_(b) and eight bits of C_(r)).However, pixels 231 and 232 share the same chrominance components 224and 226. This pattern is repeated for successive pair of pixels,thereby, effectively, requiring only 16 bits of data to represent asingle pixel (two pixels in 32 bits of data).

This mode of operation allows the processor 130 to gain a 33% saving inthe amount of data that must be passed to the OSD unit from the memory,i.e., a reduction in the size of the OSD bitstream. More importantly,the number of available colors for each OSD region has been increaseddramatically without having to increase the size of the OSD palette. Infact, the increase in hardware requirements, if any, is minimal.

FIG. 3 illustrates a method 300 for constructing an OSD bitstream withTrue Color Mode. The method is generally recalled from a storage device,e.g., a memory, and executed by the processor 130. The OSD bitstream isgenerated by the processor 130 and is processed by the OSD unit 150.Method 300 constructs an OSD bitstream by generating an OSD headerhaving a true color mode bit, followed by a plurality of data bytes oftrue color pixels.

Referring to FIG. 3, the method 300 begins at step 305 and proceeds tostep 310 where a bit in the OSD header is designated as a true colormode bit. If the True Color Mode is enabled in the OSD header, then theOSD data bytes following the header define true color pixels. If theTrue Color Mode is not enabled, then the OSD data bytes are treated inaccordance with a normal format, which may be a 4-bit address to apalette (or any other bitstream formats, e.g., the MPEG standards).

In step 320, method 300 determines whether the True Color Mode isenabled. If the query is negatively answered, method 300 proceeds tostep 325 where the OSD data bytes are generated using a non-true colorformat. Method 300 then proceeds to step 340.

If the query at step 320 is affirmatively answered, method 300 proceedsto step 330 where a plurality of true color pixels is disposed withinthe OSD data bytes. Each true color pixel comprises three OSD databytes, where each OSD data byte has a length of 8-bit. Since thechrominance components are repeated for successive pixels (or everyother set of chrominance components is discarded), two OSD pixels can bedisposed within four OSD data bytes.

In step 340, method 300 determines whether there is another OSD headerfollowing the OSD data previously processed. A new OSD header may berequired if the various modes represented by the function bits 212 aremodified. Similarly, a new header is required for each new OSD region ona frame. If the query is negatively answered, method 300 proceeds tostep 350 where method 300 ends. If the query is affirmatively answered,method 300 proceeds to step 320 where the steps of 320-330 are repeatedfor each additional OSD header. In this manner, the OSD bitstream maycomprise both true color OSD data bytes and non-true color OSD databytes.

There has thus been shown and described a novel method and apparatus forconstructing an OSD bitstream defining true color pixels. Many changes,modifications, variations and other uses and applications of the subjectinvention will, however, become apparent to those skilled in the artafter considering this specification and the accompanying drawings whichdisclose the embodiments thereof. All such changes, modifications,variations and other uses and applications which do not depart from thespirit and scope of the invention are deemed to be covered by theinvention, which is to be limited only by the claims which follow.

What is claimed is:
 1. Method of constructing an on-screen display (OSD)bitstream, said method comprising the steps of:forming a bitstreamincluding an OSD header having a bit for indicating one of a true colormode and a non true color mode; and generating OSD data defining colorvalues of an OSD pixel when the bit indicates said true color mode and apalette address for the OSD pixel when the bit indicates the non truecolor mode.
 2. The method of claim 1, wherein said OSD data definescolor values for a plurality of pixels, each of said color valuescomprising a luminance component and a chrominance component.
 3. Themethod of claim 2, wherein a pair of true color pixels share the samechrominance component.
 4. The method of claim 3, wherein said pair oftrue color pixels comprises two successive true color pixels.
 5. Themethod of claim 4, wherein an arrangement of said pair of true colorpixels comprises a first luminance component, followed by said sharedchrominance component, followed by a second luminance component.
 6. Themethod of claim 2, wherein said luminance component of a true colorpixel is set to all zeros to implement a transparent mode.
 7. The methodof claim 1, wherein said OSD data generating step is implemented withoutusing a palette.
 8. An OSD bitstream stored in a storage mediumcomprising:a header having a bit for indicating one of a true color modeand a non true color mode; and a plurality of OSD data bytes, coupled tosaid header, defining color values of an OSD pixel when the bitindicates said true color mode and a palette address for the OSD pixelwhen the bit indicates the non true color mode.
 9. The OSD bitstream ofclaim 8, wherein said color value of each of said plurality of OSD databytes comprise a luminance component and a chrominance component whenthe bit indicates said true color mode.
 10. The OSD bitstream of claim9, wherein a pair of true color pixels share the same chrominancecomponent.
 11. The OSD bitstream of claim 10, wherein said pair of truecolor pixels comprises two successive true color pixels.
 12. The OSDbitstream of claim 11, wherein an arrangement of said pair of true colorpixels comprises a first luminance component, followed by said sharedchrominance component, followed by a second luminance component.
 13. Themethod of claim 9, wherein said luminance component of a true colorpixel is set to all zeros to implement a transparent mode.
 14. Apparatusfor generating an OSD bitstream comprising:a storage medium for storingan OSD header having a bit for indicating one of a true color mode and anon true color mode and OSD data coupled to said header, said OSD datadefining color values of an OSD pixel when the bit indicates said truecolor mode and a palette address for the OSD pixel when the bitindicates the non true color mode; and a processor, coupled to saidstorage medium, for enabling said bit within said header to indicatesaid true color mode and for reading said OSD header and said OSD dataupon enabling of said true color mode bit.
 15. The apparatus of claim14, wherein said storage medium is a read only memory (ROM).
 16. Theapparatus of claim 14, wherein said storage medium is a random accessmemory (RAM).
 17. Apparatus for generating an OSD message comprising:astorage medium for storing an OSD bitstream including a header having abit for indicating one of a true color mode and a non true color modeand OSD data coupled to said header, said OSD data defining color valuesof a plurality of OSD pixels when the bit indicates said true color modeand a palette address for the plurality of OSD pixels when the bitindicates the non true color mode; and a processor, coupled to saidstorage medium, for programming said bit within said header to indicatesaid true color mode and formatting said OSD data to define the colorvalue of each of said plurality of OSD pixels; and an OSD unit, coupledto said processor, for processing said OSD bitstream to form the OSDmessage.